• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The present invention relates to a computer-implemented method for managing establishment-linked drink treats between different users, which users registered with an account are executable on a mobile application on a mobile device with a display.
    公开号:BE1026739B1
    申请号:E20195398
    申请日:2019-06-19
    公开日:2020-06-02
    发明作者:Troyer Pieter De
    申请人:Coupon Solutions Comm V；
    IPC主号:
    专利说明:

    METHOD AND PLATFORM FOR MANAGING TRAKTATIOS
    TECHNICAL DOMAIN N
    The invention relates to an improved computer-implemented method for managing treats, with a specific application to beverage treats as a preferred embodiment.
    STATE OF THE ART
    The applicant aims to provide a computer-implemented method for managing establishment-linked drink treats between different users via a mobile application. On the one hand, it was noted that there is currently no valid system in the market that is suitable for this, and that related systems, such as Ching®, which has since been closed down, focus on cash register management of individual cases, which tackles a lot of other problems. The applicant further notes that the method is transferable to applications other than drinks treats, and thus more generally to food, but even to the wider application of general coupons for a particular store (establishment), without (or with limited) constriction to certain products.
    A first object of the present invention is to securely transfer a treat from a first user to a second user (typically a different one, but may be the same as well). It is crucial that the treat cannot be intercepted or consumed by a third party who is not entitled to it.
    A second object of the present invention is to enable a simple, specific way (establishment-bound) of treating a user remotely to a particular consumption (drink, food or other), whereby the person who effectively takes care of the consumption (operator of establishment, 'validator', or 'validator') can automatically read and process all necessary information.
    An additional goal is to easily manage costs incurred during a group visit (two or more users) to an establishment without the need for cash transactions. For example, it is no longer necessary to create a 'pot', recalculate who has to pay what to whom, or search for small change when paying between the different parties.
    BE2019 / 5398
    The present invention aims to solve at least some of the above-mentioned problems.
    SUMMARY OF THE ONION TVI NDI NG
    The invention relates to a computer-implemented method for managing establishment-linked treats between different users, the method comprising the following steps:
    a. receiving and storing information from a first user in a central server, which first user is registered with an account on a mobile application, which application is executable on a mobile device with a display, regarding a new treat for a second user , which information is provided via a mobile device where the first user is logged in to the mobile application via his account, which information includes at least the following information:
    i. identification data of the first user, preferably a user name of his account for the mobile application and / or telephone number, preferably wherein the identification data of the first user is automatically provided by the mobile application;
    ii. identification data of the second user, preferably a user name of his account for the mobile application and / or telephone number of the second user, which identification data of the second user is provided by the first user;
    lil. establishment to validate the beverage treat, the establishment being selected from a predetermined list of establishments from the central server by the first user;
    iv. drink treat treat data at least comprising number, and optionally identification, of treated consumption units, wherein the identification of the treated consumption units from a predetermined consumption list of the central server is selected by the first user, being the predetermined consumption list depending on the selected establishment, and verifying that prior to the beverage treat, the first user has a credit to consumption units for the selected establishment on his account on the mobile application that is at least equally
    BE2019 / 5398 is large as the number of consumption units of the drink treat;
    wherein the treat data is provided after selecting the establishment;
    b. decreasing the credit of the first user for the selected establishment by the number of consumed units treated;
    c. after receiving the drink treat information for the second user, detecting from the central server the login of the second user to his account on the mobile application;
    d. upon detection of the login of the second user, sending from the central server the information regarding the beverage treat to the mobile device to which the second user is logged in;
    e. generating an optical, machine-readable representation, preferably a QR code, based on an order of consumptions at the establishment by the second user, by a display device to which an account is associated, which is associated with the establishment. machine-readable representation for a mobile device is displayed on a display of the establishment, and which representation is uniquely validable by a mobile device to which the second user's account is logged, the generated representation including information on the number of consumptions of the order , and the type of consumptions of the order;
    f. reading in the optical representation via the mobile application on a mobile device with video capacity to which the account of the second user is logged in;
    g. processing the optical representation on the mobile device to which the second user is logged in, whereby the number of consumption units associated with the order and / or the number of consumptions and type of consumptions are displayed on the mobile device, requesting approval from the second user prior to crediting the number of consumable units from the second user's account to the establishment's account;
    h. communicating, after approval of the second user, to the central server of the approval, whereby the credit of the second user for the selected establishment is reduced by the number of consumption units of the order;
    BE2019 / 5398
    i. reporting approval to the second user's account and the establishment's account, as well as updating the second user's credit.
    As indicated, in a preferred embodiment the treats refer to foodstuffs (where the establishments are food and / or drink establishments such as cafes, bars, tea rooms, restaurants, brasseries, festivals, etc.), and most preferably to drink treats ( the establishments being drink establishments, such as cafes, bars, tea rooms, restaurants, brasseries, festivals, etc.).
    Note that steps a, b, c and d must be carried out in the order mentioned, and can be performed at the most (partly) simultaneously.
    DESCRIPTION OF THE FL GUREN
    Figure 1A-F shows a flow for the partial method of creating a new treat.
    Figure 2A-D shows a flow for the partial method of retrieving and validating a treat.
    Figure 3A-D shows a flow for the partial method of creating a new treat according to a preferred embodiment of the invention.
    Figure 4A-E shows a flow for the partial method of retrieving and validating a treat according to a preferred embodiment of the invention.
    DETAILED DESCRIPTION
    Unless otherwise defined, all terms used in the description of the invention, including technical and scientific terms, have the meaning generally understood by those skilled in the art of the invention. For a better assessment of the description of the invention, the following terms are explicitly explained.
    BE2019 / 5398 “A”, “the” and “it” refer to both singular and plural in this document unless the context clearly assumes otherwise. For example, "a segment" means one or more than a segment.
    The terms "include", "include", "consist of", "consist of", "include", "contain", "contain", "include", "include", "contain", "contain" are synonyms and are inclusive or open terms that indicate the presence of what follows, and that do not exclude or prevent the presence of other components, features, elements, members, steps known from or described in the prior art.
    The term "establishments" refers to businesses where certain goods are sold. In a more specific embodiment, this concerns food and / or beverage stores or catering establishments (café, restaurant, tea room, brasserie, hotel, etc.) where the food and / or drink is consumed on the spot, and in an even more specific embodiment, focus on one industry (for example, only café and the like).
    Quoting numerical intervals through the endpoints includes all integers, fractions, and / or real numbers between the endpoints, including these endpoints.
    In a first aspect, the invention relates to a method according to claim 1. A first user hereby has the option, from his account on the mobile application on his mobile device, typically a smartphone or the like, to send a treat to a second user ( whether or not different from the first user). A first advantage here is the ability to provide others with a treat over a distance in a particular establishment, and preferably at a particular festival. This may either target the known presence (or future known presence) of the second user in said establishment, or may also encourage the second user to visit said establishment to consume the treat. In order to initialize the treat, the first user must provide the necessary information, which makes the treat traceable on the one hand (both for possible refund and for the information of the second user), but also meticulously, in the sense that the treat is only provided by the second user can be consumed. Logically, the content of the treat can also be determined by the first user. This is typically done by selecting the establishment where the treat is to be validated (consumed) from a predefined list of establishments registered with the mobile application as an establishment.
    BE2019 / 5398 This can be done by searching the list by name of the establishment, by location, by proximity to the first user or from a specific point. In a possible embodiment, even under certain circumstances (for example, between users sharing location with each other via the mobile device and / or via the mobile application itself), it can be based on (proximity to) the location of the second user.
    Following the selection of the desired establishment, the mobile application can optionally request a consumption list from the central server, which list is associated with said establishment. This list includes a list (typically defined by the establishment) of possible consumptions, and preferably the price (per piece, per kg, per ten, etc.). In this list, the first user can then indicate which drinks and how much they wish to treat to the second user. Alternatively, however, one can simply work with a number of consumption units which are typically equivalent to a fixed monetary value, with the first user choosing to provide X number of consumption units to the second user.
    In addition, identification data of the second user is entered by the first user. The second user can be selected from an existing list (eg "friends", or imported from phone book / facebook / other social media), or selected based on the second user's username and / or phone number.
    It is important to note that the second user, the recipient, does not necessarily have to already have an account for the mobile application, since the treat only becomes valid when the recipient logs in to the application. Meanwhile, the treat data is stored on the server associated with the second user's phone number. In this sense, the second user who receives a treat based on his phone number that is not linked to an account can receive a notification (e.g. via SMS, e-mail and / or other media) (the notification can optionally also indicate how he or she can download the application and / or create an account). The notification may also already provide certain information about the treat, for example one or more of the following: first user (donor), establishment to validate the treat, (full or partial) treat details, deadline for validation, etc.
    The first user identification data is also provided with the information associated with the treat, and is typically provided automatically by the mobile application.
    All previous information is provided to a central server, typically via a wireless internet connection from the mobile device. The central server stores the
    BE2019 / 5398 information under one and the same virtual entity, namely the treat that is involved.
    Preferably the user will also pay automatically when sending the information, preferably via an in-account credit line.
    Note that the execution (validation) of monetary transactions is generally known through optical recognition, such as through QR codes. For this reason, the current document will not go into more detail here, given that these techniques are known and have not been adapted specifically to the current application.
    In a preferred embodiment, upon logging into an account, the information regarding all drink treats linked to said account is retrieved from the central server, preferably wherein the information is retrieved when specifically requesting the information from said account. By updating the information, on request and / or automatically, a quasi real-time overview can always be maintained, which ensures that transactions are possible in the short term (also because there is direct interaction between accounts, and not between bank accounts or such), and whatever stops the 'expiration' of the treats.
    The term “drink treats” can refer to either a very specific indication of the type and number of consumptions that a user wishes to transfer to a second user, but can also refer only to the number of consumptions in the form of a credit, where a consumption is a single , has a fixed credit value (cf. drink coupons), and a giver chooses how many drinks to transfer, after which a recipient can choose how they are validated. In particular, the second interpretation is the most preferred one in the present invention, where a donor wishes to transfer a number of "vouchers" to a recipient, without associating a particular consumption that limits the recipient.
    “All drink treats linked to said account” may be both the drink treats where said account occurs as that of a first user (giver) and the drink treats where said account occurs that of a second user (recipient). Alternatively, this refers only to the drink treats where said account acts as that of a second user. A still further alternative may be a request from the account to retrieve the information of all drink treats linked to said account again, the account being that of a second user; and can request from the account for it
    BE2019 / 5398 re-fetching the information of all drink treats linked to said account, the account being that of a first user.
    In a preferred embodiment, the establishments in the predetermined list include one or more associated accounts, and where validating a generated representation by a mobile device to which an account is logged in is associated with the establishment, the validation of said beverage treat is sent to the central server and the validation with associated validation data is stored with the information regarding said beverage treat.
    Such an account that is linked to an establishment has a number of additional options compared to the 'normal' user accounts. Such accounts may also not have some options that ordinary user accounts do, since such a master account is actually linked to a commercial entity, and therefore has certain limitations. In general, a master account is suitable for generating representations, which includes information about the number of consumptions of an order (and optionally the type of consumptions). However, representations can only be validated if a validating user's account contains sufficient credits linked to the said establishment (if for another establishment, typically an error message indicating the wrong establishment will appear and the treat not validated and thus remains 'open' on the central server). When an order of a correct master account is validated by a user with sufficient credits, the validation is sent to the central server, and the validation data is stored with the information of the treat, which is then closed. The validation data is typically time of day, master account identification data (e.g., multiple master accounts associated with one establishment), content of the validated treat, etc.
    In a preferred embodiment, the second user may partially accept a received treat to be included in his credit, namely in terms of treat data and, in particular, number and / or identification of treats consumed, for validation. The pre-existing treat is hereby adapted to the selected treat data.
    In a preferred embodiment, a user can initialize a new beverage treat via the mobile application by using said mobile application
    BE2019 / 5398 to provide information regarding the new beverage treat, said information further comprising: expiration date of the beverage treat and / or duration of validity of the beverage treat; or wherein a new drink treat is automatically provided with a predetermined expiry date and / or predetermined period of validity of the drink treat, said expiry date and / or period of validity depending on the establishment of the drink treat and / or the time of initialization of the drink treat.
    For example, by making it possible to add an expiration date to the treat, it can be ensured that donors will get their money back over time if a treat is not used, so that credits don't end up outstanding. In addition, this also gives a greater incentive to the recipient to use the treat, which is certainly interesting for treats that are given, for example, as advertisements (eg by owner establishments).
    In a preferred embodiment, an account associated with an establishment from the predetermined establishments list is adapted to be linked to a digital accounting system, whereby a validation of a drink treat to said establishment account is automatically passed to the digital accounting system, which further provided with the treat data. The advantages of such a linked system speak for themselves, and also prevent possible fraud, and can serve as additional confirmation to the tax authorities that all income is declared.
    In a preferred embodiment, each account is associated with a unique username and a unique telephone number, preferably with a bank account number associated with each account. Note that the credit line of an account can be replenished through multiple channels and different bank accounts (actually little to no limitation in this matter), but the associated bank account number is used for (partial) credit refunds, expired non-validated treats, etc. instance, a refund of expired / non-validated treats will be made to a credit of the user in question who created the treat. Preferably, however, it is possible from the mobile application to transfer existing credits back to the associated bank account.
    In a preferred embodiment, a user pays his own initialized beverage treats through a virtual account-linked credit, preferably upfront, which credit can be electronically funded.
    BE2019 / 5398
    An internal credit line associated with a user account guarantees, on the one hand, to the owner of the establishment that the funds for the treat are available. By providing funds on the line of credit, the giver (first user) is also assured that he or she will be able to use it (for themselves or others), instead of relying on a mobile banking application that will then resume in the original application must be opened to make payments.
    In a preferred embodiment, a real-time overview of non-validated drink treats for the said account can be requested from the central server via an account, preferably whereby a historical overview of validated drink treats for the said account can be requested from the central server.
    This improvement is especially useful for a user to keep a record of outstanding treats, preferably with information regarding any term or expiration date.
    In a preferred embodiment, through an account associated with an establishment from the predetermined list of establishments, a real-time overview of non-validated beverage treats for said establishments can be retrieved from the central server.
    As the owner of an establishment, it may be useful to encourage certain users to use a treat so that it is not lost, but also to see to what extent self-offered treats are used or not by recipients. In addition, it also provides the operator with an overview of expected income for the coming period.
    In a preferred embodiment, when selecting the establishment when initializing a beverage treat by a user, the user can search the predetermined list based on geographic location, preferably by city or town.
    In a preferred embodiment, through an account associated with an establishment from the predetermined list, the predetermined consumption list for said establishment can be edited, with the editing adding, changing
    BE2019 / 5398 and includes the removal of consumptions on the consumption list, as well as adding, changing and removing the price of said consumptions.
    In a preferred embodiment, a user may divide a non-validated beverage treat with multiple treated drinks into separate drink treats, each comprising at least one treated drink, the total number of treated drinks of the divided individual drink treats being at most equal to the number of treated drinks of the non-validated split drink treat.
    In particular, this option can be particularly helpful in spreading a treat over an entire evening. For example, a user can treat another user 10 pints or colas, but it is of course not easy to redeem them in one go, especially since it is not easy to meet with 9 others by a certain deadline. In this way, the recipient can select, for example, one or two consumptions from the treat, and split them off and convert them into a new treat (or vice versa, split off the rest and convert them into a new treat) which can even be passed on to a third user. This way one can only use the desired drinks with the desired number, and the other drinks are not lost.
    Furthermore, also in a possible embodiment, multiple treats for a particular user can be combined into a single treat by the user. This can be done locally, on the application and mobile device itself, or on the central server controlled from the application. However, upon validation of the (provisional) new merged treat, a new treat would be (definitively) created on the central server, and the merged treats indicated as validated on the central server.
    In a preferred embodiment, the drink treat information further comprises a time stamp.
    In a preferred embodiment, non-validated beverage treats received on a first account can be passed, partially or completely, to a second account, thereby defining a new beverage treat, whereby from the first account the consumables to be passed and their number can be defined .
    BE2019 / 5398 In a preferred embodiment, the first and second users can be the same user.
    The main advantage of this is that a user can give himself a certain budget in advance to consume, which on the one hand can impose a certain limitation on him or her, but on the other hand also allows him to work completely cashless when visiting the establishment.
    In a preferred embodiment, the validating party receives no information regarding the treat regarding the identity of the first user and / or of the second user.
    In the most preferred embodiment, the sending of the information by the first user is performed by a swipe movement on a display of the mobile device on which the first user is logged in with his account on the mobile application.
    In what follows, the invention is described by means of non-limiting examples illustrating the invention, which are not intended or should be interpreted to limit the scope of the invention.
    EXAMPLES
    Example 1: Creating a new treat
    Figures 1A-B-C-D-E-F show an example of creating a new beverage treat according to the method, specifically the steps of providing the information regarding the beverage treat. In Figure 1A, the user selects an establishment by entering its name (in part), then searches for it in the predefined list of establishments, and displays matching entities, from which the user can then select (or simply advance on only one hit for the search term). Once the establishment has been selected, the user will enter an overview of the possible consumptions for the establishment, shown in Figure 1B, which overview is predetermined for each establishment separately. Here the user can choose which drinks and how much he or she wishes to treat.
    In a next step, visible in Figure 1C-D, the recipient or second user can be chosen, choosing from one or more of the proposed criteria, namely to themselves, from a username of an account of a user of
    BE2019 / 5398 the mobile application, or via a user's telephone number. Preferably only the first two options will be possible. The sender may still have to choose between multiple users who meet the same user name, which can then be further distinguished on other data, such as a specified location or telephone number.
    Finally, in Figure 1 E, you can choose how you pay, via an online payment (mobile banking for example), or via a credit linked to the account.
    Once this data is provided, the treat can be officialized and the information passed to the central server as a new drink treat (Figure 1F).
    Example 2: Using a treat
    In a first user interface (Figure 2A), the user can make a number of choices, including 'cashing'. This will bring the user into an overview of outstanding treats (Figure 2B) for their account, with in this case further information such as treat details, donor identification details (first user), shelf life, and establishment for validation. The user can make a selection here, for example the first treat (Figure 20), in which the related information is displayed. The user can request that the representation be generated, in this case a QR code that can (only) be read by the account of the establishment for validation. Confirmation follows after successful reading (Figure 2D).
    It is believed that the present invention is not limited to the embodiments described above and that some modifications or changes to the described examples can be added without revaluating the added claims. For example, the present invention has been described with reference to drink treats (in cafes, tea rooms and the like, but it should be understood that the invention can be applied to e.g. general food treats (extend application to restaurants too) or even more generally to coupons or coupons in chain stores.
    Example 3: Creating a new treat
    Figure 3A shows a first user interface of a first user, in which a number of establishments (festivals in this case) are listed by the user for whom he wishes to create (purchase) a number of consumptions. When selecting one of the festivals (establishments), as 'Rock Zottegem' was chosen in Figure 3B
    BE2019 / 5398, the available credit is visible at said festival (5 vouchers), with a number of options, such as offering the available credit ('Buying vouchers'), as well as treating consumptions to a second user ('Swiping vouchers') . Finally, it is also possible to validate a consumption ("place order (redeem vouchers at the bar)").
    Figure 30 shows the display on choice to pass a treat to a second user. On the one hand, you can choose the number of consumption units that wish to be treated ("2 coupons"). Note that in certain embodiments this can also be implemented by choosing specific types of consumptions and corresponding numbers. Then the beneficiary recipient, or second user, must be selected. This can be looked up from a pre-existing list of 'friends' or 'acquaintances', but it can also be found via a general search function by name or other identification (customer number, telephone number, etc.) belonging to the account of the second user, with the search performed on the full user list. In this case, "Simon D" was searched, on which two hits appeared, one of which can subsequently be designated as a second user. Finally, the chosen treat can be sent to the selected second user, as shown in Figure 3D.
    Example 4: Using a treat
    From the perspective of a manager or person with access to an account linked to an establishment, this can be entered for a specific order, whereby the number of consumption units equivalent to the order can be calculated automatically or manually and an optical, machine-readable representation , in this case a QR code is generated, which contains this information on a display linked to the account of the establishment. This is visible in Figure 4A, where in addition to the QR code itself, the number of consumption units is also visually displayed for verification by the user which validates.
    From the user side (Figure 4B) we see the possibility to validate the QR code. This is done after choosing "Place order" from an earlier menu (see Figure 3B), where the camera of the user's electronic device is controlled, and thus the QR code can be read. After reading in, the information from the QR code is converted and communicated to the user, whereby at least the number of consumption units linked to the order is visually communicated on the user's electronic device ('Redeem 3 vouchers'), after which they place the order can explicitly approve or reject ('Yes' or 'No'), as shown in Figure 40. Upon approval, this is communicated (typically via WiFi) to the central server, which
    BE2019 / 5398 then also communicated to the provider of the QR-coder (device on which the festival account is logged in), which receives a notification with further details such as name, time and information about the number of consumption units, as shown in Figure 4D. Conversely, as shown in Figure 4E, the user who validates the order can also be notified of the approval, with the information showing further information related to the identity associated with the festival account, such as the name.
    权利要求:
    Claims (13)
    [1]
    CONCLUSI ES
    A computer-implemented method for managing establishment-related beverage treats between different users, the method comprising the following steps:
    a. receiving and storing information from a first user in a central server, which first user is registered with an account on a mobile application, which application is executable on a mobile device with a display, regarding a new drink treat for a second user , which information is provided via a mobile device where the first user is logged in to the mobile application via his account, which information includes at least the following information:
    i. identification data of the first user, preferably a user name of his account for the mobile application and / or telephone number, preferably wherein the identification data of the first user is automatically provided by the mobile application;
    ii. identification data of the second user, preferably a user name of his account for the mobile application and / or telephone number of the second user, which identification data of the second user is provided by the first user;
    iii. establishment to validate the beverage treat, the establishment being selected from a predetermined list of establishments from the central server by the first user;
    iv. drink treat treat data at least comprising number, and optionally identification, of treated consumption units, wherein the identification of the treated consumption units from a predetermined consumption list of the central server is selected by the first user, being the predetermined consumption list depending on the selected establishment, and verifying that the first user has, prior to the beverage treat, a credit to consumables for the selected establishment in his account on the mobile application that is at least as large as the number of consumable units of the beverage treat;
    BE2019 / 5398 where the treat information is provided after selecting the establishment;
    b. decreasing the credit of the first user for the selected establishment by the number of consumed units treated;
    c. after receiving the drink treat information for the second user, detecting from the central server the login of the second user to his account on the mobile application;
    d. upon detection of the login of the second user, sending from the central server the information regarding the beverage treat to the mobile device to which the second user is logged in;
    e. generating an optical, machine-readable representation, preferably a QR code, based on an order of consumptions at the establishment by the second user, by a display device to which an account is associated, which is associated with the establishment. machine-readable representation for a mobile device is displayed on a display of the establishment, and which representation is uniquely validable by a mobile device to which the second user's account is logged, the generated representation including information on the number of consumptions of the order , and the type of consumptions of the order;
    f. reading in the optical representation via the mobile application on a mobile device with video capacity to which the account of the second user is logged in;
    g. processing the optical representation on the mobile device to which the second user is logged in, whereby the number of consumption units associated with the order and / or the number of consumptions and type of consumptions are displayed on the mobile device, requesting approval from the second user in advance crediting the number of consumption units from the second user's account to the establishment's account;
    h. communicating, after approval of the second user, to the central server of the approval, whereby the credit of the second user for the selected establishment is reduced by the number of consumption units of the order;
    BE2019 / 5398
    i. reporting approval to the second user's account and the establishment's account, as well as updating the second user's credit;
    whereby non-validated beverage treats received on a first account can be passed, partially or completely, to a second account, thereby defining a new beverage treat, whereby from the first account the consumptions to be passed and their number can be defined.
    [2]
    The computer implemented method of the preceding claim 1, wherein the display of the establishment simultaneously displays the number of consumption units of the order simultaneously with the optical representation.
    [3]
    The computer-implemented method of any one of claims 1 or 2, wherein the credit of an account for an establishment is quantified by an integer number of consumption units, and the credit of the account is displayed upon approval of crediting the consuming units of the order.
    [4]
    The computer implemented method according to any of the preceding claims 1 to 3, wherein, when logging into an account, the information regarding all drink treats linked to said account is retrieved from the central server, preferably wherein the information is retrieved when specifically requesting the information from said account.
    [5]
    The computer implemented method according to any of the preceding claims 1 to 4, wherein an account associated with an establishment from the predetermined establishments list is suitable for linking to a digital accounting system, whereby an approved order from said account of the establishment is automatically communicated to the digital accounting system, which is further provided with the number of consumptions and the type of consumptions of the order.
    [6]
    The computer implemented method according to any of the preceding claims 1 to 5, wherein each account has a unique username
    BE2019 / 5398 and a unique telephone number are associated, preferably with a bank account number associated with each account.
    [7]
    The computer-implemented method according to any of the preceding claims 1 to 6, wherein a user prepays own initialized beverage treats via a virtual account-linked credit, which credit can be provided electronically with funds.
    [8]
    The computer implemented method according to any of the preceding claims 1 to 7, wherein the approval of the second user logged into his account does not require identity verification.
    [9]
    The computer implemented method according to any of the preceding claims 1 to 8, wherein when selecting the establishment when initializing a beverage treat by a user, the user can search the predetermined list based on geographic location, preferably on city or municipality.
    [10]
    The computer implemented method according to any one of the preceding claims 1 to 9, wherein through an account associated with an establishment from the predetermined list, the predetermined consumption list for said establishment can be edited, adding, editing, and deleting of consumptions on the consumption list, as well as adding, changing and removing the price of said consumptions.
    [11]
    A computer-implemented method according to any one of the preceding claims 1 to 10, wherein a user can divide an unvalidated beverage treat with multiple treated drinks into separate drink treats, each comprising at least one treated drink, wherein the total number of treated drinks of the divided individual drink treats is at most equal to the number of consumed drinks of the non-validated drink treat to be divided.
    [12]
    The computer implemented method according to any of the preceding claims 1 to 11, wherein the beverage treat information further comprises a time stamp.
    BE2019 / 5398
    [13]
    The computer implemented method according to any one of the preceding claims 1 to 12, wherein the first and second user may be the same user.
    类似技术:
    公开号 | 公开日 | 专利标题
    US10810557B2|2020-10-20|Financial services ecosystem
    US10902420B2|2021-01-26|Merchant configured advertised incentives funded through statement credits
    US20140229397A1|2014-08-14|System and method for managing charitable donations
    US7243839B2|2007-07-17|Systems, methods, and devices for selling transaction instruments
    CN108027921A|2018-05-11|System and method for promoting the Secure Transaction in non-financial institution's system
    US10068265B2|2018-09-04|Creating revenue sources using allocation source
    US20110054987A1|2011-03-03|Point of Sale System for Reconciling Sales Information with a Sales Incentive
    US20140108177A1|2014-04-17|Social gifting and efficient gift redemption
    US20140172633A1|2014-06-19|Payment interchange for use with global shopping cart
    US20090327121A1|2009-12-31|Monetary gift registry methods and systems
    US20140214626A1|2014-07-31|Methods for enabling gift card transactions
    US20140095276A1|2014-04-03|Method and system for offering combinations of goods and services for purchase and controlling expenses
    US20200111139A1|2020-04-09|Payment interchange for use with global shopping cart
    WO2018005635A2|2018-01-04|Physical, logical separation of balances of funds
    Singh1999|Electronic money: understanding its use to increase the effectiveness of policy
    US8706626B2|2014-04-22|Systems and methods for provisionally transferring an electronic currency
    JP5068284B2|2012-11-07|Prepaid payment system using credit card number and method of prepaid payment
    Kumar et al.2017|Demonetization and its impact on adoption of digital payment: Opportunities, issues and challenges
    Horne et al.2016|Gift cards: a review and research agenda
    US20210398196A1|2021-12-23|Method and platform for managing gifts
    BE1026739B1|2020-06-02|METHOD AND PLATFORM FOR MANAGING TREATS
    KR20100121873A|2010-11-19|A financial service system for internet community
    KR100375913B1|2003-03-15|A method for managing exposure of bank deposit using internet
    Alemu2018|Opportunities and Challenges of EthSwitch E-Payment System: A case study of Commercial Bank of Ethiopia
    de Barros2016|Electronic Payments Workflow Optimization in Fashion E-tail
    同族专利:
    公开号 | 公开日
    BE1026737A1|2020-05-27|
    BE1026739A1|2020-05-27|
    BE1026737B1|2020-06-02|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20140129392A1|2011-07-13|2014-05-08|Shinichi HANAYAMA|Gift system|
    US20140095218A1|2012-09-28|2014-04-03|Gregg J. Golembeski|Virtual gift card gifting or sharing|
    法律状态:
    2020-08-10| FG| Patent granted|Effective date: 20200602 |
    优先权:
    申请号 | 申请日 | 专利标题
    BE20185765A|BE1026737B1|2018-10-31|2018-10-31|METHOD AND PLATFORM FOR MANAGING TREATS|PCT/IB2019/059333| WO2020089821A1|2018-10-31|2019-10-31|Method and platform for managing gifts|
    US17/289,779| US20210398196A1|2018-10-31|2019-10-31|Method and platform for managing gifts|
    [返回顶部]